We are IntechOpen, the world's leading publisher of Open Access books Built by scientists, for scientists

Open access books available 5,300

130,000 155M

International authors and editors

Downloads

Our authors are among the

most cited scientists 154 TOP 1%

Selection of our books indexed in the Book Citation Index in Web of Science™ Core Collection (BKCI)

# Interested in publishing with us? Contact book.department@intechopen.com

Numbers displayed above are based on latest data collected. For more information visit www.intechopen.com

# **Securing the Home Energy Management Platform**

Søren Aagaard Mikkelsen and Rune Hylsberg Jacobsen

Additional information is available at the end of the chapter

http://dx.doi.org/10.5772/62923

#### **Abstract**

Energy management in households gets increasingly more attention in the struggle to integrate more sustainable energy sources. Especially in the electrical system, smart grid systems are envisioned to be part in the efforts towards a better utilisation of the energy production and distribution infrastructure. The Home Energy Management System (HEMS) is a critical infrastructure component in this endeavour. Its main goal is to enable energy services utilising smart devices in the households based on the interest of the residential consumers and external actors. With the role of being both an essential link in the communication infrastructure for balancing the electrical grid and a surveillance unit in private homes, security and privacy become essential to address. In this chapter, we identify and address potential threats Home Energy Man‐ agement Platform (HEMP) developers should consider in the progress of designing architecture, selecting hardware and building software. Our approach starts with a general view of the involved stakeholders and the HEMS. Given the system over‐ view, a threat model is constructed from the HEMP developer's point of view. Based on the threats that have been detected, possible mitigation strategies are proposed taking into account the state of the art of technology for securing platforms.

**Keywords:** smart grid, IoT, security, privacy, cloud, web service, service‐oriented ar‐ chitecture

# **1. Introduction**

A smart grid is a vision of a more intelligent electrical infrastructure. It is envisioned to provide a more reliable and effective electrical grid in the process of integrating more intermittent renewable energy sources, like wind power and solar power. This will demand for systems that

© 2016 The Author(s). Licensee InTech. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

will continuously monitor and manage end‐points of the grid, for example, an end‐point as the residential sector that consumes around 31% of the electricity worldwide [1]<sup>1</sup> . These systems are known as Energy Management Systems (EMSs)<sup>2</sup> . EMSs aim at utilising the grid capacity more efficiently in terms of instantaneous demand and generation. This includes flattening the peak demand by giving the demand‐side awareness about the time periods it is "smart" to con‐ sume energy [2].

Ensuring security and privacy are becoming important issues to address with the deployment of smart meters. Smart meters are devices that record the electric consumption and production and communicates this information automatically to the utility. Research has shown that information from smart meters can reveal personal habits and disclose details about the residents living there. Furthermore, the situation exacerbates if additional meters and actuators are installed on the most consuming devices for Direct Load Control (DLC) in the demand response paradigm. Therefore, security and privacy enhanced system architectures suggest, a Home Energy Management System (HEMS) that runs locally inside the residential home, among other things to resolve privacy issues.

**Figure 1.** The considered stack for a HEMS.

This chapter describes security and privacy issues for a HEMS in an SOA. It focuses on the Home Energy Management Platform (HEMP) provider [also in other contexts referred to as the Original Equipment Manufacturer (OEM)]. A HEMP provider is responsible for the platform, which the software developers and service providers can deploy their software and services on as seen in **Figure 1**. A HEMP provider creates the platform that facilitates security and privacy in several layers. Following a holistic approach, a threat modelling approach is used that considers the interdependencies between stakeholders of the system before identi‐ fying the threats the system faces. A risk assessment is made on the identified threats, and

<sup>1</sup> Percentage based on the average electricity consumption from residential domains in Spain, Norway and Denmark.

<sup>2</sup> EMSs can refer to not only systems that support the operation of the electrical grid on a transmission and distribution level but also systems that automatically control and monitor energy usage in buildings.

possible mitigation strategies are presented based on a review of the state of the art in hardware security. Based on the threat analysis, recommendations to create a secure HEMS are provided.

# **2. Background and related work**

A preliminary review of the domain is presented before developing a threat model for the HEMP. The review includes a description of general threat modelling approaches together with commonly used diagrams to perform the analysis.

## **2.1. Threat modelling approaches**

Threat modelling is a systematic approach that supports the process of finding the appropriate technical solutions for enforcing security and privacy. It considers the potential threats with the greatest impact and addresses these first.

There are generally three approaches to threat modelling [3]:


When comparing the approaches, the system‐centric approach more tightly couples with the development process, whereas the asset‐centric approach and attacker‐centric approach can be considered more "detached" and are typically performed separate from the software development.

#### *2.1.1. Diagrams for threat modelling*

The typical diagrams for revealing threats focus on describing the domain or the data flows within the considered system. The goals of these diagrams are to create a common view of the system and to make the communication paths visible. These diagrams provide an abstraction

<sup>3</sup> Is often called *software-centric*, but for the sake of generality we use the term *system-centric*.

of the system which allows system architects and software developers to create a common view of the system and define the system boundaries.

The Unified Modelling Language (UML) [4] is general‐purpose modelling language that specifies a set of diagrams for modelling systems. It provides a standardised way of modelling systems and provides two fundamental representations of a system: behavioural models and structural models. Behavioural models, such as use case diagrams, can be beneficial to identify stakeholders and describe a proposed functionality. Structural models, such as class diagrams, are useful for describing the domain which includes objects, attributions, operations and relationships.

Data Flow Diagrams (DFDs) have traditionally been used for threat modelling, since the threat problems tend to follow the data flow not the control flow [3]. It is used for describing how data enter and leave the system. The basic elements for modelling the system are shown in **Table 1**. The system is typically modelled with specific scope, where the external system that provides the system with data is modelled using the *external entity* element. The system of interest consists of a number of *processes* and *data stores* with *data flow* between them. To define the boundary between trust elements and non‐trusted elements, DFD also includes trust boundaries. Trust boundaries visualise where data flows intersect between the system and a malicious actor.

**Table 1.** The basic elements of a DFD.

By modelling the specific system with DFD elements, it is possible to map these elements to the STRIDE threats. For instance, an external entity for the system can generate a *spoofing* threat, that is, an external entity can pretend to be something or someone else than originally thought of. By enforcing an authentication mechanism, it is possible to mitigate the threat if the external entity was trying to *spoof* a person or a thing.

# **2.2. Home energy management software platforms**

As depicted in Figure 1, the HEMS consists of a software platform that provides the middle‐ ware for interoperable communication between devices and services. In the following, two open source EMSs are presented. Both use the OSGi (Open Service Gateway Initiative) architecture that specifies a modular and service‐based software platform implemented in Java.

# *2.2.1. OpenHAB*

The openHAB project<sup>4</sup> is an open software framework that focusses on enabling home automation by joining systems and technologies available in the smart home domain. It allows for automation rules and offers a single user interface for all such systems. The openHAB software is capable of running on any device that supports the Java Virtual Machine (JVM). The architecture consists of three main components: the OSGi framework, openHAB Core Components and openHAB Add‐ons. The OSGi framework and the openHAB Core Compo‐ nents represent the internal communication infrastructure and base libraries. The openHAB Add‐ons include a large set of protocol bindings that map between other home automation protocols to an abstract data model. It includes an "item" repository, where an item can be interpreted as an abstraction for a property a device can actuate. The openHAB framework provides mechanisms for securing the communication to the openHAB software platform, but does not have additional security features beside what the OSGi framework can provide.

# *2.2.2. OGEMA*

Open Gateway Energy Management (OGEMA)<sup>5</sup> is an open software framework for smart grid services. It represents a system that supports building automation control and energy man‐ agement for residential and industrial environments. The framework rests on a hardware‐ independent platform with a common execution environment for all deployable services. OGEMA uses the OSGi Java framework enabling a modular and dynamic software environ‐ ment. The OGEMA framework consists of the following entities:


<sup>4</sup> http://www.openhab.org/

<sup>5</sup> http://www.ogema.org/

The OGEMA architecture embeds three "modes" of security: standard infrastructure, a controlled environment and proof of security [5]. Furthermore, it isolates third‐party applica‐ tions which can be integrity checked using the public key of the service provider. This is similar to Android's permission handling [5]. Since OGEMA framework is restricted to security capability of the OSGi Java framework and the JVM, it is possible for a malicious component to freeze the platform by allocating too much memory or changing shared variables. A possible solution to this issue is the I‐JVM presented in [6].

# **2.3. Threat analysis of the smart grid domain**

Cyber‐Physical Systems (CPSs) and Internet of Things (IoTs) are two research domains that overlap and share similar challenges with the smart grid domain. In [7], they identify four key challenges in designing a secure IoT which include data management, identity management, trust management and privacy. Based on these challenges, they propose hardware‐based mitigation strategies that include Physical Unclonable Function (PUF) for data provenance, integrity and identity management. However, they present a non‐systematic approach where the stakeholders are not clearly identified. In reference [8], they consider threat modelling issues of CPSs. The authors provide a generic model of a CPS and present a case study with a road vehicle. In reference [9], researchers present a survey of security theories, analysis, simulation and application fields but without giving recommendations.

In reference [10], they present a structured method for identifying security threats in smart home scenarios. It is based on a context pattern for the elicitation of domain knowledge for the smart home domain. Using the context pattern for creating DFDs for the smart domain, they identify the entry points and vulnerabilities. This allows them to define the attack paths from entry point to the assets of the system. Their method is sound and structured but lacks possible threat mitigation strategies.

# **3. Threat modelling of a home energy management platform**

Security experts are encouraging designers to make explicit statements about the security assumptions, when designing and implementing systems. Defining the security assumptions is the first step in order to find the vulnerabilities of a system. With a description of the vulnerabilities, it is possible to assess the risks a given design exposes. Security technologies can then be enforced where the vulnerabilities need to be addressed.

## **3.1. Methodology**

A systematic approach is necessary to discover all the vulnerabilities of a system [10]. Our approach for designing a HEMP is shown in **Figure 2**, consisting of five steps. The methodology is based on the work presented in references [3, 10, 11], but adapted to our work.

The following gives a description of the six steps in our method:

**Step 1. Define context and objectives—**The context represents the identification of the main stakeholders of the system, the general system architecture and the desired objectives. The purpose of this step is to create the scope of interest and focus on the analysis. Part of the context is the review of regulations with the smart grid area and to describe the considered use cases. This includes also defining the dependency between stakeholders. With the definition of the context and objectives, requirements can be elicited.

**Step 2. Define DFD—**Using the previously defined context, the flow of information is modelled through DFDs. Context elements are mapped to elements that present input/output, processes, data flow and data storage. In the modelling process, the context can be refined, for example, adding additional stakeholders or modifying the system architecture. Furthermore, it supports the process of modelling the domain knowledge to DFD elements. With the process of defining the context and modelling, the DFD represent the high‐level system description.

**Step 3. Identify assets and vulnerabilitiesbased on DFD elements—**Based on the DFD elements representing the HEMP, the system's assets and threats are identified. Assets represent valuable targets for an attacker and are therefore of interest for the attacker. Assets can be both physical and linked to a process. One approach to identify threats for the identified assets is the STRIDE‐per‐element or STRIDE‐per‐interaction approach [3].

**Step 4. Risk impact assessment based on attack trees—**With explicit threats, the risk impact assessment can be performed using attack trees. The step assesses how noticeable and with what likelihood a threat is. The outcome of this assessment can be either accepted or mitigated using a technical solution. An accepted risk represents a possible attack, but it is typically regarded as unlikely.

**Step 5. Selection of mitigation approach—**If a threat is unacceptable, a selection of a mitiga‐ tion solution must be considered. The solution can be based on possible software or hardware technologies that consider an attacker with the same power or more. Mitigation can require a different hardware or software solution. The risk assessment of the threat can help in deter‐ mining the threat mitigation should be placed in the hardware or software.

#### **3.2. Stakeholders, system architecture and objectives**

In **Figure 3**, the major stakeholders of the HEMS are presented. The residential consumer enables the deployment of HEMSs. Trust to the system, reduction of/control of electricity bills, addressing environmental concerns and better comfort (i.e., provision of technical solutions for better control of own energy use) are the main motivational factors for the residential consumers to adopt a smart grid solution [12]. Smart device vendors build sensors and actuators deployed in homes, for example, Wink,<sup>6</sup> SmartThings<sup>7</sup> or Vera<sup>8</sup> represent an envi‐ sioned smart device vendor. Often these vendors can be categorised whether or not they provide a total home automation solution or have upgraded an existing product to be IoT‐ enabled. In the envisioned system, the Distribution System Operator (grid operator) is not directly interacting with the HEMS, instead it depends on the smart grid services developed by service providers and deployed by the service market responsible. Services utilise infor‐ mation retrieved from the residential homes and electric grid, to improve electricity usage for both the residential consumers and grid operator. For connecting the services and the smart devices, a communication service provider (CSP) is needed. The software platform providers create the software platform, where services can be executed.

**Figure 3.** Overview of the major stakeholders of the HEMS. It is inspired by [32].

The HEMS is considered to be placed in an SOA, where there exist home‐oriented and grid‐ oriented services. The services are implemented as web services based on the REpresentational

<sup>6</sup> http://www.wink.com/

<sup>7</sup> https://www.smartthings.com/

<sup>8</sup> http://getvera.com/

State Transfer (REST) architectural style. The system considers many‐to‐one mapping between the residential consumer and the DSO, that is, the home‐oriented services are executed for each residential consumer, whereas the grid‐oriented services utilise the output for optimising the operation for the DSO.

The rationale of the system architecture is that the home‐oriented services will optimise according to demands of individual homes, whereas the grid‐oriented services will support the operation of the electrical grid. Since grid‐oriented services can be highly valuable for the grid responsible (DSO), these will foster the development of the home‐oriented services. A fundamental requirement for the approach is that the services can be used as *building blocks* for delivering additional services. For a more detailed insight into the system, the reader is referred to references [13, 14].

The main characteristics of a service‐oriented system are [15]:


The domain model is depicted in **Figure 4** using a UML class diagram together with the main stakeholders. It is composed of classes (rectangular icons), packages (folder icons) and actors (stick figures). It considers the domain to consist of two major parts: a s*ervice market* and a *residential home*. Both parts include a number of elements (represented as classes) that represent the implementation by a stakeholder. At this stage, only elements that are relevant for an identified stakeholder are considered. The relationship between the elements indicates the

**Figure 4.** Domain model of the system.

multiplicity and type of association. Besides the basic UML arrows representing the associa‐ tions, two other arrows are drawn. The dependency between the stakeholders is modelled with an open arrow to visualise how stakeholder's business objectives are associated with other stakeholders. A closed arrow indicates the realisation of the element.

In the process of defining hardware recommendations for the HEMP developer, focus is set on the HEMP developer as depicted and highlighted in **Figure 3**. As seen in Figure 4, the HEMP developer has several dependencies—either directly or indirectly.

To this end, the objective of the HEMP developer for the HEMS is the following:

*The HEMP will provide a security and privacy enhanced platform for service developers to deploy on web service on, while being a trustworthy platform for the residential consumers, service providers and the grid responsible.*

# **3.3. Requirements**

To identify the security threats and vulnerabilities of the HEMP (see Section 3.5), the necessary requirements, which the platform must adhere to, have to be explicitly stated. An explicit set of requirements can guide the process of designing a platform which is resistant to possible attacks. Furthermore, it allows for a risk assessment of third‐party services installed on the device.

Requirements are usually understood as stating *what* a system is supposed to do—contrary to *how* it should do it [16]. It characterises the desired functional behaviour and performance, whereas non‐functional requirements aim at fulfilling a desired property. Non‐functional requirements are usually judged by the operator of the system and relate more to the system architecture, whereas functional requirements are testable.

In the following, both the functional and non‐functional requirements for the HEMP will be presented. The requirements are classified according to the direct stakeholders for the HEMP developer. The rationale is that the requirements and dependencies from the stakeholders will have an impact on the threats and thereby on the mitigation strategies that technical solutions can provide. The listed requirements are derived from use cases and requirements specified in references [14, 17–19].

# *3.3.1. Software platform developer*

An essential feature of the HEMS is to provide an environment for executing services relevant for external actors in the smart grid. This includes services with real‐time dependencies or not. These services can be manufactured by different service providers and therefore depend on an *isolated execution environment*, if a single service should not crash the system. Moreover, software trends dictate a continuous development and maintenance process to follow an agile development life cycle and fix newly discovered vulnerabilities. Thus, doing updates to the services is vital for its sustainability. Finally, a software platform is responsible for delivering the "knobs" of the smart devices for services and external system to interact with in a secure way. The requirements are as follows:

**R1**. The HEMS shall support execution of real‐time dependent services, like services for controlling a residential battery according to external signals.

**R2**. The HEMS employ separation mechanisms to securely isolate services.

**R3**. The HEMS shall be able to upgrade existing services.

**R4**. The HEMS shall support remote software updates from the software framework devel‐ opers for managing services.

**R5**. The HEMS shall provide security measures appropriate for the protection of integrity and confidentiality of services.

These requirements relate to service providers which represent the main stakeholder of the software platform developer.

# *3.3.2. Smart device vendor*

End devices in the smart grids often represent the load of the electrical system. Giving these devices the ability to communicate with other devices facilitates information to be dissemi‐ nated to all stakeholders. For the smart devices to be part of the smart grid, a communication infrastructure in the Home Area Network (HAN) that incorporates a heterogeneous set of communication protocols is essential [20, 21]. Furthermore, for smart devices to provide a secure communication path, it is necessary to enable end‐to‐end encryption. The smart device vendors' requirements are as follows:

**R1**. The HEMS shall support multiple communication protocols for the HAN.

**R2**. The HEMS shall provide smart device vendors with the ability to extend the set of communication drivers easily.

**R3**. The HEMS shall facilitate end‐to‐end encryption between smart devices and the services that utilise and control the smart devices.

Besides depending on the physical communication technology implemented on the HEMS, software drivers are also necessary to provide an interface for a service.

# *3.3.3. Residential consumer*

The intelligent automation of the smart grid depends on the residential consumers. They will be an integral part that will ensure reliability of the electrical grid by modifying the way energy is used. A HEMS can support the behavioural change but requires the acceptance of the residential consumer. It is generally believed that a user‐centric approach is vital, where trust to the system remains one of the priorities [12]. The requirements for a residential consumer are:

**R1**. The HEMS must secure the confidentially and integrity of meter data.

**R2**. The HEMS should provide residential consumers the ability to install and uninstall services on demand.

### **3.4. Data flow diagram of the home energy management platform**

The main purpose of DFDs is to identify the key *data flows* in the system. Modelling the data flows, contrary to the *control flows*, reveals how information is exchanged throughout the system. A DFD model explains who takes part in a process for delivering the information, the information needed to complete a process and what information is stored.

**Figure 5** provides an overview of the internal data flows on a HEMS and the HEMS interactions with the external entities based on reference [14]. Besides the DFD symbols presented in **Table 1**, the DFD is annotated with dotted lines indicating the trust boundaries. These are quantified three trust levels from the HEMP provider's point of view. Furthermore, it contains dotted arrows between processes, to indicate how a process affects another process's runtime. These are useful for expressing hardware‐related issues.

**Figure 5.** DFD of the HEMS.

As seen in Figure 5, seven processes are included in the model. This includes two services: third‐party HEM service and a Meter Data Management (MDM) service. The MDM service is explicitly included to show the data flow of meter data and storage of the smart device configurations. The third‐party HEM service presents any high‐level service useful for smart grid operations. The service manager and software framework manager relate to the contin‐ uous maintenance of the software on the HEMS. Lastly, there is a system manager and device manager for the physical interaction with the HEMS.

#### **3.5. Threat analysis**

A threat model is a depiction of a system's attack surface. An attack surface has numerous threats towards a set of assets within the system. The purpose of mitigation techniques is to protect the assets from a possible attacker. The envisioned attacker can be assigned capabilities, such as being able to have physical access to the system or only have access through the network. Other attackers include social engineers which through "social" interaction can gain unauthorised privileges to the system. This could be attackers using phishing emails to exploit vulnerable code in installed software.

The threats for the HEMP provider are a combination of the indirect threats that the software platform provider faces and the external entities that have physical access to the HEMS. In the following, we classify the considered attacker, identify the assets of the HEMS and elicit a subset of vulnerabilities.

# *3.5.1. Assets of the HEMS*

Assets represent valuable targets for an attacker, and therefore naturally represent the system susceptibility for threats. In the following, the key assets are identified with a description of the reason for its inclusion:

**Services:** These represent both value‐added services for the residential consumer, but also account for the foundation of service market generation. A compromised service can lead to cyber attacks on homely property. Furthermore, it can also lead to violation of the intellectual property for the service provider, thus undermining a service market. The services are dependent on the software platform provider to secure the services, where it assumes the underlying software stack (e.g., virtual machine, Operating System (OS), etc.) will not be compromised. The services can contain a range of sensible information regarding the residen‐ tial consumer, for example, granular meter data, personal identifiable information, crypto‐ graphic key sets and so on.

**Service manager:** This process is responsible for presenting, installing, updating and unin‐ stalling services on the HEMS. It is in direct contact with the residential consumer and service market provider. An attack on the service market manager can lead to undermining the service ecosystem with services unable to be update if a critical software patch needs to be installed. It depends on the given privileges from the software platform. It contains the audit of installed services and cryptographic keys to allow for a secure connection to the smart market provider.

**System manager:** This manager administrates the OS stack including middleware software (JVM, Python interpreter), system libraries and kernel (network interface, memory manage‐ ment, I/O interface, etc.), and therefore performs privileged operations. The entire software framework stack depends on its implementation. Therefore, it is assumed that it is configured and maintained reliably.

# *3.5.2. Identifying vulnerabilities*

Vulnerabilities represent an attacker's entry points to the system. It is therefore crucial to identify these entry points in order to mitigate possible attacks. Here the vulnerabilities are presented using the STRIDE‐per‐interaction approach between the service and service manager. Other interactions identified in the DFD are omitted for brevity.

#### *3.5.2.1. Services/service manager*

**T1. Spoofing**: The HEMS contacts the service market provider for exploring, installing, updating the services on Smart Market provider. If the attacker is able to insert spoofed IP packets or DNS packets when the service manager sends requests to the original Service Market site, the service manager can be sent to a site with malicious services.

**T2. Tampering**: An attacker can inject code for replacing integrity check of installed services. This will lead to malicious services being installed, which were not verified by the *service market controller*.

**T3. Repudiation:** Someone<sup>9</sup> rejects installation of a service in order to deny possible payment for energy bill.

**T4. Information disclosure**: An attacker is able to see the intellectual property of a service.

**T5. Denial of service:** If an attacker can block any communication with the service manager, the service manager cannot update installed services.

**T6. Elevation of privileges:** The HEMS supports third‐party services to be installed through the *service market provider*. If the *service market provider* is able to install a service that is able to access outside the boundary of its privileges, an attacker can access the meter data, smart device configurations.

#### *3.5.3. Attack trees*

Attack trees are useful for visualising the escalation of attacks (see **Figure 6**). The attack tree shows the root cause of an attack and what an attack subsequently after would allow an attacker to do. What would seem to be a minor attack on the system can propagate through the system, leaving assets exposed for an attacker.

In the following, the threats towards the process with the lowest trust boundary is focussed on for brevity; the "*Third‐party HEM service*" (where the MDM service is a special case). The threats **T1**, **T2**, **T4**, **T5** and **T6** can be collected from the root threat "*Install of malicious service*". The root of the attack tree is set to this threat. It is presented with the problematic state as root. Each edge in the attack tree is labelled with "{noticeable/likelihood}" measure, to indicate if the attack is believed to be noticeable and the likelihood of such an approach (**Figure 6**).

# **4. Mitigation strategies**

Often the time spend on judging the level of the risk should be compared to the time for addressing the threat. When addressing the threat, it is possible to mitigate the risk by redesigning of system architecture, implementing a mitigation feature or simply ignoring it. In the following, the chapter will review for hardware security and privacy mechanisms that mitigate the "*install of malicious service*" attack.

<sup>9</sup> The term "someone" instead of attacker is used deliberately, since it can represent the user of the system as well.

## **4.1. Security and privacy technologies**

The process of developing a secure hardware platform has recently intensified. Previously, computer security primarily focussed on creating secure software architectures and protocols with the assumption that the lower‐layer applications (e.g., the OS) would be secure. However, flaws in an OS implementation can likely lead to additional vulnerability of the application on top of it. Therefore, researchers have proposed systems for running trusted code on an untrusted OS, but there exists still pitfalls, for example, Iago attacks [22]. In the following, the concept of a Trusted Execution Environment (TEE) will be reviewed as well as technologies that use this concept.

# *4.1.1. Trusted execution environments*

In its essence, a TEE is an environment that you can *choose* to rely upon to perform sensitive tasks. The goal of TEE is to provide an isolated execution environment, secure storage, remote attestation, secure provisioning and a trusted path [23]. In hardware, it usually defines a distinguished part of the hardware architecture which is encrypted and integrity protected. It isolates an area of the processor, memory and peripherals for performing privileged opera‐ tions. Next to the TEE, a Rich Execution Environment (REE) is considered outside the Trusted Computing Base (TCB), where both an untrusted OS and untrusted third‐party services can be executed. Despite its realisation in AMD Secure Execution Environment, ARM's TrustZone technology [24], and Intel's SafeGuard Extensions (SGX) [25], it is not widely used by service

**Figure 6.** Attacks based on threats towards "Third‐party HEM service".

developers. In the following, we will examine the hardware security technologies for mitigat‐ ing the identified risk in Section 3.4.

# *4.1.1.1. ARM TrustZone technology*

The security extensions embedded in the specification of ARMv6 and later are called the TrustZone technology [24]. It provides two operational worlds: a *normal world* and *secure world*. This allows for different execution privileges for applications. For instance, an applica‐ tion responsible for handling confidential data can be executed in the secure world, without a normal application being aware about; even with vulnerabilities in the normal world's OS. The two worlds are executed through two virtual processors with hardware access controls to switch between the two worlds. The hardware access switch defines the active components in the hardware when switched. Traditionally, ARM TrustZone has primarily been used for Digital Rights Management (DRM) or banking applications, but are not restricted to those types of applications.

# *4.1.1.2. Intel SGX*

Intel's SGX extension is a set of instructions and mechanisms for managing the memory access to the Intel Architecture processors [25]. The main principle relies upon the concept of a protected memory container, also referred to as an *enclave*. The enclave can be created through application code, where sensitive data are explicitly marked. When the application is executed, a sensitive part of the application's memory space is encapsulated within an enclave. This enclave ensures that the confidentially and integrity of that memory space are sustained even with the presence of privileged malware (i.e., super‐user capabilities). Furthermore, to ensure the integrity of the application inside the enclave, Intel SGX supports CPU‐based attestation and sealing. An audited process monitors the built process of the enclave and assesses the identity of the hardware from where the enclave should be executed. Before the application is executed of the CPU, the identity of the hardware is verified through the sealing identity. It contains a digital signature (known as report) of the enclave's initial state. The enclave is then capable of receiving a report of the state, verifying its correctness. To verify that the correct software has been instantiated on the platform to remote system, it can perform an attestation with the SGX‐supported processor (known as quote). This can prove to a remote system that application has been sent to a genuine SGX implementation. The reader is referred to [26] for a thorough description of the Intel SGX technology.

# *4.1.1.3. TrustLite and TyTAN*

TrustLite [27] is a security architecture for resource constrained embedded systems that generally have to be cost effective in terms of development and production costs. The archi‐ tecture allows for software isolation with execution‐aware memory protection. The memory protection enforces a strict access control on memory by considering the program counter. Furthermore, it includes a secure exception engine that protects tasks from unauthorised exception handling. It has a secure loader that enables update of the security policy as well as prevents memory leakages after resetting the platform. However, TrustLite is static in terms of loading software components and their isolation, since this is required at boot time. TyTAN [28] leverages the TrustLite architecture for providing dynamically loading software compo‐ nents together with an integrated real‐time system.

# *4.1.1.4. Haven*

The objective of Haven security architecture [29] is to protect the confidentiality and integrity of a user's unmodified application in the cloud from an untrusted cloud provider. It is assumed that the processor is implemented correctly, but otherwise it is assumed that the adversary can access everything else, including memory and I/O devices. On software level, it is assumed that the adversary has full access to the entire software stack, including the OS, hypervisor, Basic Input/Output System (BIOS), device firmware and so on.

The inventors of Haven solve the confidentiality and integrity problem by using an *inverse sandboxing* technique also known as a *shielded execution*. Their solution is called Haven, and it leverages the Intel SGX and Microsoft's Drawbridge project [30]. Intel SGX allows application developers to protect their data from unauthorised access or modification by software that have highest privilege levels (e.g., a super‐user).

The deployment process of the Haven application is similar to the deployment of a regular cloud application, with the additional step of verifying that the process was correctly per‐ formed (the attestation from the Intel CPU). It is assumed that the cloud provider provides an Infrastructure as a Service (IaaS), that delivers the storage, hardware and networking compo‐ nents on a virtualisation platform (e.g., KVM, Xen, etc.).

## **4.2. Recommendations and conclusion**

Recommendations for a HEMP provider are given based on the vulnerabilities discovered from the threat model and the review of hardware security technologies based on TEE. Some of these recommendations reflect the challenges the security community and the hardware manufacturers are facing today, thus implementation details are still unexplored. Therefore, this chapter limits the thoroughness of recommendations to a problem description and possible approaches that need to be adapted for the HEMS. The problem description is linked to the identified requirements and threats, where the approaches are linked to the hardware technology review. The list of recommendations is as follows:

**• The HEMP should support isolation of services in terms of data and resources**: At the service layer envisioned for the HEMS, software frameworks for energy management already provide isolation of services (e.g., OSGi‐based software frameworks). However, as services become mission critical in relation to energy management, the computational resources must also be isolated. Furthermore, as services need different privileges for accessing data, the HEMS should provide a data isolation mechanism. An application isolation mechanism based on the TyTAN security architecture [28] could comply with such demands. Furthermore, it allows the use of real‐time‐dependent intelligent automation services and allows for securely installing additional communication drivers (see **R1, R2, R6, R7 R9, R10, R11**).


Constructing a HEMP, which is both secure and ensures the privacy of considered data assets, is challenging. But in order to do so, an important property for enforcing security is to *build it in* the system and not *onto* the system. This chapter contributes with a threat modelling of HEMS based on the requirement and design phases of the Microsoft Security Development Lifecycle. A domain model is constructed using UML, and the requirements are elicited from use cases for HEMS under research. A DFD models an abstract HEMS platform based on a combination of the architecture of OGEMA framework and reference architecture of a mobile platform [32]. Based on a threat analysis of the DFD, an attack tree is constructed with the focus on a malicious service attacker. Given the threats, mitigation strategies are reviewed for giving recommendations for HEMP manufacturers in the future smart grid.

# **Acknowledgements**

The research leading to these results has received funding from the EU Seventh Framework Programme (FP7/2007–2013) under grant agreement no. 317761 (SmartHG).

# **Author details**

Søren Aagaard Mikkelsen and Rune Hylsberg Jacobsen\*

\*Address all correspondence to: rhj@eng.au.dk

Department of Engineering, Aarhus University, Denmark

# **References**

